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(57) Abstract: A diagnostic instrument or data acquisition apparatus having a database for storing communications interface specifi- 
cations and other properties of diagnostic attributes (e.g., sensor measurements or operating conditions) outputted by various classes 
(models or versions) of equipment to be tested. The database records include a first field identifying a class of equipment, a second 
field identifying (e.g., by name or description) a diagnostic attribute whose value is outputted by that class of equipment, and a third 
field. The third field can specify an ID (e.g., physical signal line, physical address, or logical address) that enables a diagnostic appa- 
ratus to retrieve the value of the attribute identified by the second field from the class of UUT equipment identified by the first field 
of the record. Alternatively, the third field can identify the communications interface at which the diagnostic attribute is transmitted. 
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Communications Interface Database for Electronic Diagnostic Apparatus 

CROSS REFERENCE TO RELATED APPLICATION 

This patent application claims the benefit under 35 USC 11 9(e) of U.S. provisional 
application no. 60/451,301 filed March 1, 2003. 

FBELD OF THE INVENTION 

The invention relates generally to electronic diagnostic or data acquisition apparatus. More 
specifically, the invention is an improvement to such diagnostic apparatus comprising database 
methods and apparatus for tabulating various models or classes of equipment ("unit under test" or 
"UUT") that can be tested and, for each such class of UUT equipment, tabulating: (1) each 
diagnostic attribute whose value can be transmitted by that UUT; and (2) the ID (e.g., physical signal 
line, physical address, or logical address) and other communications interface parameters required for 
a diagnostic apparatus to retrieve the value of that attribute from that UUT. 

BACKGROUND OF THE INVENTION 

Diagnostic apparatus, also called data acquisition or data collection apparatus, is commonly 
used to test and troubleshoot various tsrpes of electronic equipment. The diagnostic apparatus 
monitors the values of electrical data generated by the electronic equipment under test ("unit under 
test" or "UUT"'). This data generally represents various sensor measurements and/or operating 
conditions of the UUT, all of which are collectively referred to as "diagnostic attributes," "collectible 
attributes," or simply "attributes" of the UUT. Maintenance personnel analyze the attribute data to 
troubleshoot or optimize the performance of the UUT. 

Maintenance personnel typically are assigned to test and troubleshoot a variety of types of 
such electronic equipment Different types and models of UUT equipment generally impose 
different interface requirements for connection to a diagnostic apparatus, because they differ from 
each other regarding the number and kind of data communications interfaces, the attributes they 
output at the data interfaces, and the ID's (physical signal line, physical address, or logical address) 
required for a diagnostic apparatus to retrieve the values of selected attributes Jfrom the UUT. In 
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fact, different interface requirements may even exist among different production versions of the same 
model of equipment 

Some conventional diagnostic apparatuses are adapted to interface with only a narrow range 
of UUT equipment models. Other conventional diagnostic apparatuses are programmable to enable 
5 them to interface with a broader range of UUT equipment, but such programming must be manually 
entered by the maintenance personnel each time the apparatus is intended to be connected to a 
different model of UUT. 

A need exists for a diagnostic apparatus capable of interfacing with a broad range of UUT 
equipment models without requiring manual reprogramming by maintenance personnel. 

10 SUMMARY OF THE INVENTION 

The invention is a diagnostic instrument or data acquisition apparatus having a database (the 
"attribute database") for storing communications interface specifications and other properties of 
diagnostic attributes outputted by various classes (models and/or versions) of equipment to be tested 
("unit under test" or "UUT"). The attribute database includes a plurality of attribute data records, 

15 each of which includes at least a first field identifying a class of UUT equipment and a second field 
identifying (e.g., by name or description) a diagnostic attribute whose value is outputted by that 
class of equipment. The attribute values (i.e., attribute data) outputted by a UUT can include sensor 
measurements and operating conditions. 

In one aspect of the invention, an attribute data record further includes a third field 

20 identifying an ID (e.g., physical signal line, physical address, or logical address) that enables a 

diagnostic apparatus to retrieve the value of the attribute identified by the second field from the class 
of UUT equipment identified by the first field of the record. For example, the ID may identify (a) a 
physical signal line or connector pin at which the UUT outputs the attribute value, (b) a logical or 
physical address that a diagnostic apparatus must send to the UUT to command the UUT to output 

25 the attribute value, or (c) a logical or physical address that the UUT outputs along with the attribute 
value in order to identify which attribute the value represents. 

In a second aspect of the invention, at least one class of UUT equipment identified in the 
database includes a plurality of communication interfaces via which a diagnostic apparatus can 
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retrieve attribute data, and an attribute data record further includes a field identifying one of said 
communication interfaces; 

In a third aspect of the invention, an attribute data record further includes a field identifying a 
chamber position or other configuration parameter that distinguishes attributes within a class of 
5 attributes. 

In a fourth aspect of the invention, an attribute data record further includes a field containing 
one or more conversion parameters, such as a scale factor, for converting an electrical signal 
outputted by the equipment to a physical unit of measurement for the attribute value identified by 
the second field. 

10 In a fifth aspect of the invention, the aforesaid first field of some or all of the attribute data 

records is a compound field that includes a plurality of subordinate fields (sub-fields) that 

collectively identify a range of equipment models, a range of equipment versions, or a range of 
equipment revision dates that define the class of equipment identified by the first field. 

In addition to the aforesaid diagnostic apparatus, other aspects of the invention are the 
15 aforesaid attribute database, the methods of storing data in the attribute database as summarized 
above, and data processing apparatuses for performing the methods. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a schematic diagram of the diagnostic apparatus of the invention connected to a 
conventional UUT which is a semiconductor manufacturing mainfi-ame having six process chambers. 
20 Figure 2 is a schematic diagram of the fields in an attribute record of an attribute database 

, according to a preferred embodiment of the invention. Subordinate fields are depicted below the 
compound field to which they belong. 

Figure 3 is a schematic diagram of the values stored in three attribute records which represent 
an exemplary attribute whose ID changes in different versions of an exemplary model of UUT. 
25 Figure 4 is a schematic diagram of two attribute records which can represent the same 

information as the three records of Figure 3. 

Figure 5 is a schematic diagram of a system in which the attribute database is remote fi-om the 
diagnostic apparatus. 
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Figure 6 is a flow chart showing the steps by which the diagnostic apparatus retrieves 
attribute data from a UUT using information stored in the attribute database. 

Figure 7 is a database table representing the attribute database having the fields shown in 
Figure 2. 

Figure 8 is a database table showing the database of Figure 7 divided into two tables. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
Conventional UUT and Diagnostic Apparatus 

Before describing the novel diagnostic apparatus and database, it will be helpful to describe 
how UUT's generally communicate with conventional diagnostic apparatuses. 

While the UUT ("unit under test") can be any type of electronic equipment, the exemplary 

UUT 12 shown in Figure 1 is similar to a semiconductor fabrication equipment "mainframe" or 
"platform" commercially sold as the Precision 5000 model by Applied Materials, Inc., the assignee 
of the present invenlion^ The illustrated mainframe is designed to integrate up to six process 
chambers 21—26 which perform various semiconductor fabrication processes. For example, three 
chambers 21, 22, 23 can be plasma chemical vapor deposition (CVD) chambers, one chamber 24 can 
be a heating chamber, and two chambers 25 and 26 can be plasma etch chambers. 

(An actual Precision 5000 includes various components that are omitted here to simplify the 
illustration, such as loadlock chambers for receiving semiconductor wafers from a carrier outside the 
mainframe and a wafer transfer robot for transferring wafers between chambers.) 

One of the functions of the UUT mainframe 12 is to provide a central communications 
interface or communications bus 31 for the chambers. Each chamber has a data port 32 connected to 
a corresponding internal data port 33 of the mainframe. The mainframe's internal data ports 33 may 
all be connected to a common communications channel 3 1 . The mainframe includes a computer 
processor (CPU) 30 that controls the sequence and operating conditions of the semiconductor 
fabrication processes performed in the process chambers and controls data transfer among all of the 
mainframe's internal and extemal data ports. The mainframe can transmit data through its internal 
data ports to the chambers so as to set the values of various chamber operating parameters, such as 
chamber pressure, pedestal temperature, and RF power. 



wo 2004/079465 



PCT/US2004/003595 



Each of the chambers also can be fitted with sensors or measurement instruments 50 to 
measure operating conditions in the chamber, such as gas pressure, RF reflected power, or the 
intensity of optical emissions at certain wavelengths. The mainframe can include additional internal 
data ports 52 to receive measurement values from the measurement instruments and to send 
5 commands for controlling the measurement instruments. 

The diagnostic attributes or collectible attributes of the UUT 12, referred to herein simply as 
"attributes," include all the operating conditions and measurement values described in the two 
preceding paragraphs. Specifically, the "attributes" of the UUT 12 are defined as the set of 
operating conditions and sensor measurements whose values can be outputted by the UUT, by the 
10 chambers 21-26 or other apparatus connected to the UUT, or by the measurement instruments 50 
connected to the chambers or the UUT. The attribute values outputted by the ULIT or any of the 
chambers or instruments attached to the UUT are collectively referred to as "attribute data". 

The UUT 12 has at least one external communications interface or I/O (input/output) port 
through which it can transmit attribute data to an external device such as a factory controller 
15 computer or a diagnostic apparatus 10. Generally the principal external communications interface is 
a digital interface 14 such as a conventional RS-232 serial port or a conventional Ethernet port. The 
UUT also may have one or more analog conununications interfaces 15, typically for the purpose of 
outputting measurement values from measurement instruments 50 that produce analog output signals 
52. 

20 A conventional diagnostic apparatus 10 intended to monitor a given type of UUT will have 

one or more communications interfaces (I/O ports) compatible with, and capable of electrical 
connection to, the external communications interfaces of that type of UUT. For example, to connect 
to the exemplary UUT, a diagnostic apparatus should have a digital communications interface 18 and 
one or more analog communications interfaces 17 respectively connected to the UUT's digital 

25 interface 14 and analog interfaces 15. (For purposes of illustration, the UUT in Figure 1 includes 
analog interfaces, whereas the commercially sold Precision 5000 mainframe does not include an 
analog interface.) 

In addition, some process chambers and some measurement instruments may output attribute 
data via digital or analog communications interfaces 54 that are not connected to the UUT. To 
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receive this attribute data, the diagnostic apparatus 10 may include additional communications 
interfaces 19 connected to the communications interfaces 54 of the chambers and measurement 
instruments. 

Because attribute data may be outputted by a UUT, by a chamber or other apparatus 
5 connected to the UUT, or by a measurement instrument coupled to such a chamber or to the UUT, 
the term "attribute data source" or simply "data source" is used herein to refer to any apparatus 
connected directly or indirectly to the UUT that can output attribute data. Furthermore, all 
references herein to attribute data outputted by a UUT are intended to include attribute data 
outputted by any attribute data source connected directly or indirectly to that UUT. 

10 The numerous conventional digital conmnmications protocols by which a UUT or other 

attribute data source can output digital data through an external communications interface generally 
fall within either of two categories: command-driven protocols and continuous streaming protocols. 

In a command-driven protocol, the data source outputs attribute data only in response to 
"read" commands received by the data source at its digital communications interface. Specifically, a 

15 diagnostic apparatus 10 can receive from the data source the value of a particular attribute only by 
transmitting to the digital I/O interface 14 or 54 of the data source a "read" command that includes 
the ID of that attribute. The ID, also called a logical address or logical port, is a digital value by 
which a UUT, or its associated attribute data source, uniquely identifies each attribute it is capable of 
outputting. By "logical" we mean that the ID need not correspond to any physical address or 

20 physical port. 

Besides responding to "read" commands, some attribute data sources also respond to "write" 
commands via the digital I/O interface 14 or 54. For example, a diagnostic apparatus or factory 
controller computer can send commands to tlie UUT that change the operating parameters of the 
chambers. 

25 In a continuous streaming communications protocol for outputting digital data, a UUT or 

other data source outputs a continuous stream of attribute data through its external digital 
communications interface 14 or 54. The attribute data typically is formatted as periodically 
transmitted frames, where each frame of data contains the current value of every attribute. In some 
data source apparatuses, each attribute is identified simply by its sequential position or offset in the 
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frame. In that case, the ID or logical address of each attribute would be its position or offset. In 
other data sources, the frame may include an ID field associated with each attribute field. The ID 
value transmitted in the ID field identifies the attribute whose value is transmitted in the associated 
attribute field. 

5 In a variant of the continuous streaming protocol, often called "trace mode" protocol, a UUT 

or other attribute data source only outputs the values of certain attributes in a continuous streaming 
format. A diagnostic apparatus can select which attributes are included in the "stream" by sending 
"trace mode" commands to the data source which identify the selected attributes. 

Semiconductor fabrication equipment that implements the published data communications 

10 standard known as SECS-2 generally can output attribute data using both a command-driven protocol 
and a trace mode protocol. 

Regardless of whether the UUT and its associated attribute data sources transmit digital 
attribute data via a command-driven protocol, a continuous protocol, or both, it is important for the 
diagnostic apparatus 10 to know the ID corresponding to each diagnostic attribute for every class of 

15 UUT with which the diagnostic apparatus will be used. 

As stated above, the UUT or its associated attribute data sources also may have one or more 
analog communications interfaces 15 for outputting measurement values from measurement 
instruments or sensors that produce attribute data in the form of analog output signals. Each analog 
interface may have one or more signal lines that can each transmit the analog value of a different 

20 attribute. In that case, it is important for the diagnostic apparatus to know which attribute 
corresponds to (i.e., is transmitted by) each signal line of each analog interface. 

Various mainframe models differ in the number of process chambers to which they can be 
connected. In mainframes 12 to which multiple chambers 21-26 can be connected, it is important to 
identify which chamber a given attribute value applies to. Accordingly, a given class of diagnostic 

25 attribute has a different ID for each chamber. An example of a "class" of attribute is chamber 

pressure. The chamber pressure in the first chamber 21 and the chamber pressure in the second 
chamber 22 would be distinguished by having different ID's. 

Various process chamber models have different classes of attributes. For example, RF power 
is an attribute of a plasma chamber but not a thermal deposition chamber, whereas heat lamp power 
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typically is an attribute of the latter but not the former. As another example, some plasma chambers 
have two RF power supplies with independently controllable powers and RF jfrequencies, while 
other plasma chambers have only one RF power supply. 

Various mainframe models also have different classes of attributes that relate to the 
5 mainframe itself rather than to one of the process chambers and that can be received or transmitted at 
the external communications interface of the mainframe. An example of a mainframe attribute is the 
position of a wafer transfer robot. Some mainframe models have only one robot while others have 
two, hence the former mainframes would not accept commands to control the position of a second 
robot or the pressure within the transfer chamber housing the second robot. 

10 Even to the extent that different UUT or mainframe models have common attributes, such as 

chamber pressure and susceptor temperature, different mainframe models typically assign different 
ID'S to those attributes. For example, for one mainframe model the chamber pressure in process 
chamber number one may have an ID of "12345", whereas the corresponding chamber pressure may 
have an ID of "ABC" for a second mainframe modeL Furthermore, those UUT's that have multiple 

15 external communications interfaces may differ in the correspondence between attributes and 

interfaces, i.e., for each diagnostic attribute, which interface and which signal line on that interface 
transmits that attribute. 

UUT's also differ in the format in which they encode the attributes. For example, they may 
differ in terms of the conversion factors required to convert the digital values which they transmit via 

20 their external communications interface to physical attributes such as temperature and pressure. 

Because of the many differences among classes of UUT's as just described, a conventional 
diagnostic apparatus typically is limited to receiving data from one model, or a small number of 
models, of UUT for which the diagnostic apparatus understands how to retrieve the attributes. 

Attribute Database 

25 My novel diagnostic apparatus 10 adds to the conventional diagnostic apparatus described 

above a novel database containing communications interface specifications enabling the diagnostic 
apparatus 10 to communicate with many different classes (models and/or versions) of UUT's 12. 
The database contains a table, referred to herein as the "attribute table" or "attribute database", that 
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stores a list of the attributes that each class of UUT can output via its external communications 
interface. For each attribute, the attribute database stores the ID that enables the diagnostic 
apparatus to retrieve the value of that attribute. 

The diagnostic apparatus can be conventional in every respect except for the inclusion of the 
5 attribute database. As described below under the heading "Hardware Implementation " the database 
can be stored on any conventional data storage device 60, which can be located within the diagnostic 
apparatus or can be located remotely and connected to the diagnostic apparatus via a 
communications network. 

In the embodiment illustrated in Figure 2, the attribute database contains a distinct database 

10 record for each combination of UUT class and attribute. That is, the attribute database contains a 

distinct group (i.e^ "set") of records for each class (model or version) of UUT equipment, and the set 
of records for a given mainframe class includes a distinct record for each attribute that can be 
transmitted to or received from that mainframe class. (Alternative embodiments for reducing the 
required number of records are described below under the headings "Version Ranges" and "Database 

15 Normalization".) 

As described above, if the UUT is a mainframe apparatus designed to be connected to various 
classes of process chambers 21-26 and/or measuring instruments, the diagnostic attributes can 
include attributes outputted by the mainframe itself, by the various classes of process chambers that 
can be attached to that mainframe, and by the various instruments that can be coupled to that 

20 mainframe or its process chambers, all of which are collectively referred to as "data source 
apparatuses". 

Each record stored in the attribute database is referred to herein as an "attribute record". 
Figure 2 shows the data fields that preferably are included in the attribute database. The left-to-right 
order of the illustrated fields is arbitrary; the fields can be stored within each database record in any 

25 physical or temporal order. 

In the embodiment shown in Figure 2, each attribute record includes every field. Alternative 
embodiments that use multiple, related database tables to reduce entry of redundant data in the 
attribute records are described below, under the heading "Database Normalization." 
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"UUT Class'^ Field 

The "UUT Class" field of each attribute record identifies the class of equipment to which the 
remaining fields in the record pertain. The attribute database can be used to store information about 
many different models of UUT's, where each model can have various versions. Accordingly, in the 
5 preferred embodiment, the "UUT Class" field has two subordinate fields called "Model" and 

"Version". The value stored in the "Model" field identifies an individual equipment model, and the 
value stored in the "Version" field identifies a specific version of the equipment model specified in 
the "Model" field. 

Any of the fields in an attribute record can be either a simple field that stores a single value or 
10 a "compound field" that stores a plurality of values. We define a "compound field" as a plurality of 
fields, which we call "subordinate fields" or "sub-fields", whose respective values collectively 

specify the value of the parameter represented by the compound field. For example, the "UUT 
Class" field described in the preceding paragraph is a compound field. The UUT Class is completely 
and uniquely identified by designating an equipment model in the "Model" sub-field and designating 

15 a version of that model in the "Version" sub-field. 

A subordinate field can itself be a compound field; that is, a subordinate field can include a 
plurality of further subordinate fields. For example, as described below under the heading "Version 
Ranges", the "Version" field can include "Version, First" and "Version, Last" sub-fields enabling the 
"Version" field to identify a range of equipment versions instead of a single version, 

20 As described below under the heading "Database Normalization," the sub-fields of a given 

compound field can be stored in different, related database tables, but still are considered sub-fields 
of the same compound field for purposed of this patent specification. 

"Attribute" Field 

The "Attribute" field contains the name of the diagnostic attribute whose ID and other 
25 properties (e.g., physical units and conversion factors) are described by the remaining fields of the 
attribute record. As stated above, diagnostic attributes of a UUT include all sensor measurements 
and operating conditions of the UUT and of all chambers, measuring instruments and other apparatus 
attached directly or indirectly to the UUT. The attribute database includes a separate attribute 
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record for each diagnostic attribute that the class of UUT identified in the "UUT Class" field is 
capable of outputting. 

For classes of UUT's that are mainfi-ames 12 designed to connect to multiple chambers 21-26 
as shown in Figure 1, it is important to identify which chamber a given attribute value applies to. 
5 Typically, the mainfi:ame will assign different ID's to distinguish the same attribute fi-om different 
chambers. 

Since an attribute that relates to a chamber is uniquely specified only if both the attribute 
name and the chamber position are specified, the "Attribute" field in an attribute record for a 
chamber-related attribute should include two subordinate fields, a "Attribute Name" field and a 

10 "Chamber Position" field, as shown in Figure 2. For every chamber-related attribute, the database 
should include a separate record for each chamber position on the mainfi-ame. This enables the 
attribute database to store (in the "ID" field of each record) the unique ID assigned by the 
mainfi*ame to each attribute associated with each chamber position. 

Conversely, if the attribute specified in the "Attribute" field relates to the mainfirame itself 

15 rather than to one of the chambers connected to the mainframe, the "Chamber Position" field has no 
relevance, so the "Chamber Position" field can be omitted, or else the value of the field can be set to 
zero or empty. 

For example, one model of mainfi-ame 12 may be capable of attachment to up to six process 
chambers as shown in Figure 1. Suppose that one of the measured attributes for each chamber is the 

20 pressure within that chamber. In that case, the Attribute Name of "pressure" will not completely 
and uniquely identify a single diagnostic attribute. Instead, a complete identification of a "pressure" 
attribute would have to specify the Chamber Position, such as "pressure in chamber 1", "pressure in 
chamber 2", etc. Generally, the mainfirame will assign six distinct ID's to be used by a diagnostic 
apparatus to retrieve the pressure measurement for the respective six chambers. These ID's will be 

25 stored in the database in the form of six distinct database records, where each record has the same 

name "pressure" stored in the "Attribute Name" field but has a distinct one of the values 1 through 6 
in the "Chamber Position" field and has the corresponding one of the six ID's in the "ID" field. 

In many cases, the "Attribute" field requires one or more additional sub-fields because the 
Attribute Name and Chamber Position do not suffice to uniquely determine the ID required to 
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retrieve the attribute. Figure 2 illustrates that one possible additional sub-field is "Chamber Model". 
As described above under the heading "Conventional UUT and Diagnostic Apparatus," the 
mainframe UUT 12 shown in Figure 1 can be connected to several different types of chambers, such 
as plasma CVD chambers 21-23, heating chamber 24, and plasma etch chambers 25, 26. 
5 Furthermore, a given chamber type generally may be available in several different models. For 

example. Applied Materials commercially sells different models of plasma etch chambers under the 
model names "MxP", "MxP+", and "Super-e". The "Chamber Model" field should store sufficient 
information to identify the chamber type and model, such as "MxP Etch". 

Although some classes of diagnostic attributes are shared by these different chamber types 
10 and models, different chamber models often will not assign the same ID to a given diagnostic 

attribute. For example, the ID required to retrieve the cathode temperature may be "123" for a model 
MxP attached to the mainframe at chamber position 6 and "456" for a model "Super-e" chamber at 
the same position. In this example, therefore, the three sub-fields "Attribute Name", "Chamber 
Position", and "Chamber Model" are required to completely and uniquely identify a diagnostic 
15 attribute^ such as "cathode temperature in an MxP Etch chamber at position 6"^ which would be 

represented by an attribute record in which the values stored in these three respective fields would be 
"cathode temperature", "6", and "MxP Etch", respectively. 

Figure 2 labels the "Chamber Model" sub-field as "Chamber Model or Config" to denote that 
one or more other parameters representing the configuration of the UUT or the chamber can be 
20 substituted for the Chamber Model in this field. 

For classes of UUT's that have only a single, permanent process chamber, such as ion 
implant machines, the "Attribute" field need not include any sub-fields. In that case, the "Attribute" 
field should perform the same function as the previously described "Attribute Name" sub-field, i.e., 
it should store the name or description of the diagnostic attribute whose properties are described by 
25 the remaining fields of the attribute record. 

Bach attribute record optionally may further include a "ReadAVrite" field as shown in 
Figure 2. This field may be used to store a logical "flag" that indicates whether the diagnostic 
attribute specified in the "Attribute" field: (1) can be read (i.e., retrieved or collected) but not 
modified by a diagnostic apparatus; (2) can be read and modified (i.e., "written"); or (3) can be 
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modified but not read. 

"Interface & Protocol" Field 

As shown in Figure 2, each attribute record preferably includes an "Interface & Protocol" 
field. If the UUT has more than one extemd communications interface 1 8 such that the different 
5 external interfaces output different diagnostic attributes, then the value stored in the "Interface & 

Protocol" field should identify which physical interface of the UUT outputs the diagnostic attribute 
specified in the "Attribute" field. Likewise, if the UUT can have chambers or instruments with 
external interfaces separate from those of the UUT, the "Interface & Protocol" field identifies which 
of these interfaces can output the attribute specified in the "Attribute" field. 

10 The "Interface & Protocol" field preferably should identify the analog or digital hardware 

protocol and, optionally, the low level communications protocols by which the UUT outputs 
attribute data at the specified interface. Examples of hardware protocols that might be employed at 
different communications interfaces are RS-232 and Ethernet. Examples of communications 
protocols that different UUT's might employ are SECS, GEM, and IP. The "Interface & Protocol" 

15 field also can be used to specify the type of electrical connector used for that interface, such as DB- 
9, DB-25 or RJ-45. All the hardware and communications protocols mentioned in this paragraph are 
published standards. 

The "Interface & Protocol" field can be omitted from the attribute database if all the UUT 
classes recorded in the database employ the same communications protocol for outputting attribute 

20 data, and if none of the UUT classes requires more than one external communications interface to 
output the attribute data. 

The reason the interface and protocol are represented by a single field in Figure 2 is that the 
communications protocols used at a given interface generally will be the same for all diagnostic 
attributes outputted at that interface. That is, a UUT or other data source would not employ 

25 different protocols for outputting different diagnostic attributes via the same interface. Therefore, 

there is no need to permit the interface and the protocols to be specified independently of each other 
in separate fields. 

However, in actual programming of the database structure, it may be more convenient to 
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divide the "Interface & Protocol" field into separate sub-fields for each level of hardware and 
conomunications protocol discussed in the preceding paragraph. A common practice in designing a 
relational database would be to define a "Interface & Protocol" table having separate fields for each of 
these protocol levels. The "Interface & Protocol" table should be "related" to the "Attribute" table 
5 shown in Figure 2 via the "Interface & Protocol" field in the "Attribute" table. 

"ID" Field 

The "ID" field contains the ID that enables a diagnostic apparatus to retrieve (i.e., read or 
collect) the value of the diagnostic attribute identified by the "Attribute" field from the class of UUT 
equipment identified by the "UUT Class" field of the attribute record. As explained earlier, a UUT 
10 conventionally assigns a unique ID to every diagnostic attribute it can output firom a given external 
conmiunications interface. 

The meaning of the ID depends on the type of communications interface and protocol 
employed by the UUT for outputting that diagnostic attribute. As just discussed, the 
communications protocol preferably is specified in the "Interface & Protocol" field. 
15 If the "Interface & Protocol" field specifies an analog interface with multiple signal lines 

carrying different attribute data, the "ID" field should identify which signal lines (e.g., which pins on 
an electrical connector) carry the specified attifibute. 

If the "Interface &. Protocol" field specifies a digital interface using a command-driven 
communications protocol, the "ID" field should specify the logical or physical address that must be 
20 included in a "read" command sent from the diagnostic apparatus to the UUT in order to retrieve the 
attribute specified in the "Attribute" field. 

If the "Interface & Protocol" field specifies a digital interface using a continuously streaming 
communications protocol, the "ID" field should specify the logical or physical address transmitted 
by the UUT to identify the attribute data, or the logical address or offset that identifies the position 
25 of the specified attribute data within a "frame" of data that is periodically outputted by the UUT. 

Hardware Implementation 

As explained above, a UUT 12 has at least one external communications interface 14 through 
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which it outputs attribute data. The diagnostic apparatus 10 should have a communications interface 
18 compatible with, and connected to, the external communications interface 14 of the UUT. The 
diagnostic apparatus can have a number of communications interfaces of different types to permit 
connection to different types of interfaces on different classes of UUT's. 

5 If the UUT 12 is a conventional semiconductor fabrication tool or mainframe, its external 

commTmications interface 14 generally will be a digital interface complying with the well known RS- 
232 serial communications standard, and it will transfer data in response to the commands specified 
in the published "SECS" communications protocol that is widely adopted in the semiconductor 
industry. A diagnostic apparatus 10 for monitoring such semiconductor mainframes conventionally 

10 can include a general purpose "PC" computer 62 running the well known Windows, Macintosh, or 
Linux operating system. Alternatively, the diagnostic apparatus 10 can include a computer 62 
specifically intended for monitoring semiconductor fabrication tools, such as the "Blue Box" model 
computer sold by MKS Instruments, a company in Andover, Massachusetts. Either type of 
computer 62 commonly has an RS-232 serial port 18 that can be connected to the RS-232 port of the 

15 UUT via a conventional serial cable. Conventional data collection and anal^^sis software can be 
installed on the computer. Such software can control data transfer through the communications 
interfaces of the diagnostic apparatus in compliance with the communications protocol used by the 
UUT, such as the SECS protocol, so as to retrieve desired attribute data from the UUT. The 
software also can present the retrieved attribute data to service personnel, store or "log" tlie data in a 

20 conventional computer storage device 60, signal an alert upon detecting the occurrence of certain 

conditions in the retrieved attribute data, and perform statistical analysis of the data. For example, 
software with these capabilities is commercially sold by MKS Instruments and by Brookside 
Software, a company in San Carlos, California. 

In operation, a human user will instruct the diagnostic apparatus to retrieve certain attribute 

25 data from the UUT. The instruction may be in the form of a manually typed command, a push 

button, or a computer program stored by a user in the diagnostic apparatus that specifies a sequence 
in which several attributes should be retrieved in accordance with a data collection plan. These are all 
conventional features of the aforesaid, commercially available, data collection software and computer 
hardware. 
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To implement our invention, the attribute database described above can be added to one of 
the just-described conventional diagnostic apparatuses 10 that is based on a programmable computer 
62. 

The attribute database records can be stored on any conventional data storage device 60, such 
5 as one or more computer hard disk drives. The logical structure of the attribute database, in the form 
of the records and fields described in this patent specification, can be implemented by 
straightforward programming of any conventional database management system (DBMS) software 
installed on a conventional computer 62. DBMS software is commercially sold by various software 
companies such as Microsoft, IBM and Oracle. Open source SQL DBMS software also is publicly 
10 available. Of course, the data storage device can be connected to the computer by any conventional 
data interface. 

That attribute database and the DBMS software can be installed on the data storage device 60 
and the computer 62 within the diagnostic apparatus 10 shown in Figure 1. Both the DBMS 
software and the previously described data collection and analysis software can be installed and 
15 simultaneously running on the same computer 62. 

More preferably, as shown in Figure 5, the attribute database and the DBMS software can be 
installed on a data storage device 64 and a server computer 66 at a remote location. The diagnostic 
apparatus 10 can connect to the server computer 66 via a conventional data communications link 68, 
such as a local area network, a wide area network, or a point-to-point link via telephone. The DBMS 
20 software installed on the server computer 66 preferably has multi-user server capability so that 
many diagnostic apparatuses 10 at different locations can simultaneously access the database. 

For example, the data storage device 64 on which the attribute database is installed can be 
located at a central office where it can be readily updated fi-om time to time to include new models 
and new versions of UUT's. Portable diagnostic apparatuses 10 can be carried to customer sites 
25 throughout the world to service customer-owned UUT's. Each diagnostic apparatus can access the 
database via a communications link 68, 

If the attribute database is installed on a remotely located 64 and server computer 66 as 
shown in Figure 5, then each diagnostic apparatus 10 should include a computer 62 in which 
conventional database client software has been installed. Such software is conventionally capable of 
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sending a request via the communications link 68 to the server computer 66 whenever the diagnostic 
apparatus needs to retrieve a database record, such as to determine the ID or other properties of an 
attribute. The computer 62 within each diagnostic apparatus 10 also should include the previously 
described conventional software for communicating with the UUT to retrieve attribute data. 

5 Operation 

Before the diagnostic apparatus is used to retrieve attribute data jfrom a given class (model 
and version) of UUT, the previously described attribute records (Figure 2) which characterize the 
diagnostic attributes for that class of UUT should be stored in the attribute database. Generally, the 
manufacturer of the UUT supplies the ID and other properties of each diagnostic attribute that the 

10 UUT is capable of transmitting. Therefore, the user of the diagnostic apparatus can acquire such 

attribute properties from the UUT manufacturer and store the information in the attribute database 
in accordance with the database structure described above. Preferably, the manufacturer of the UUT 
can store the information directly in the database (i.e., build or populate the database) to avoid the 
need for tiie user to acquire the infomiation from the manufacturer and reformat it for storage in the 

15 database. 

Figure 6 is a flow chart showing the steps by which a diagnostic apparatus 10 retrieves 
attribute data from a UUT using the previously described attribute database. These steps preferably 
are implemented by straightforward programming of the computer 62 within the diagnostic 
apparatus. The software that implements the following Steps 601 - 607 is referred to herein as the 

20 Attribute Look-Up software. The Attribute Look-Up software preferably is installed in the same 
computer 62 within the diagnostic apparatus 10 that runs the conventional data collection and 
analysis software described under the heading "Hardware Implementation". All of this software can 
run simultaneously on the computer. 

Step 601 : The diagnostic apparatus must identify what class (model and version) of UUT it 

25 is connected to. Some conventional UUT's are capable of identifying themselves in response to a 
command sent by the diagnostic apparatus to a digital communications interface 14 of the UUT. 
With UUT's that lack such capability, the person using the diagnostic apparatus is responsible for 
identifying the UUT and providing this information to the diagnostic apparatus, such as via 
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keyboard input. As explained in the preceding sections entitled "Attribute Database" and "UUT 
Class Field " the information required to uniquely identify a class of UUT includes a model 
designation, and a version designation (e.g., version number or version date) may be necessary to 
uniquely identify the class of UUT if different versions have different attribute properties. 
5 Step 602: Optionally, if the attribute database is stored on a remote server 66, the diagnostic 

apparatus can transfer from the server's storage device 64 to its local storage device 60 a copy of all 
the attribute records for the identified class of UUT, that is, all attribute records whose "UUT Class" 
field matches the class of UUT identified in Step 601. This optional Step 602 eliminates the need to 
maintain a continuous communications link 68 with the remote server during subsequent operation of 

10 the diagnostic apparatus, since the communications link is required only during this Step 602, This 
step is accomplished by a database client software on the local computer 62 sending a query to 
DBMS server software on the server computer 66. 

Step 603: The diagnostic apparatus must identify one or more attributes that service 
personnel select to retrieve from the UUT. The selected attributes may be manually identified by 

15 keyboard input, or may be specified in a data collection plan that service personnel previously stored 
in the computer of the diagnostic apparatus. This step may be performed before, after, or 
concurrently with Step 601 . For attributes that are associated with a chamber attached to a multi- 
chamber UUT, the identification of the attribute should include identifying the chamber model, 
chamber position, and any other applicable chamber configuration parameters, as explained in the 

20 preceding section entitled "Attribute Field.'' 

Step 604: For each attribute selected in Step 603, the diagnostic apparatus queries the 
attribute database to retrieve the one attribute record corresponding to both the UUT class identified 
in Step 601 and the selected attribute. If optional Step 602 was performed, the diagnostic apparatus 
can search the attribute records transferred to its local storage device in Step 602 to find the one 

25 attribute record whose "Attribute" field matches the selected attribute. Otherwise, conventional 

database client software on the local computer 62 should send a query to DBMS server software on 
the server computer 66 to retrieve the one attribute record whose "UUT Class" field matches the 
UUT class identified in Step 601 and whose "Attribute" field matches the selected attribute. 

Step 605: For each attribute record retrieved in Step 604, the diagnostic apparatus reads the 
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ID of that attribute from the "ID" field of the record. If such fields are included in the attribute 
record, the diagnostic apparatus also reads the interface and protocol information from the "Interface 
& Protocol" field of the record, and reads the read/write flag from the "Read/Write" field of the 
record. 

5 Step 606: The diagnostic apparatus now retrieves the actual attribute data from the external 

communications interface of the UUT using the ID, the interface information, and the protocol 
information from Step 605. If the UUT and its associated data sources collectively have more than 
one external communications interface, the interface information specifies from which interface the 
diagnostic apparatus should retrieve the attribute data in this step. The protocol information 
10 specifies the retrieval method required by the UUT; it typically will be one of the methods described 
in the preceding sections entitled "Conventional UUT and Diagnostic Apparatus" and "Interface & 
Protocol Field". 

For example, if the UUT 12 employs a command-driven protocol for outputting that 
attribute data, the diagnostic apparatus sends to the UUT a "read" command specifying the ID. As 

15 another example^ if the UUT transmits the attribute data in a continuous streaming protocol as 
described above, the diagnostic apparatus 10 uses the ID of the desired attribute to locate the 
attribute data in the stream of data from the UUT. Alternatively, if the UUT outputs the specified 
attribute at an analog interface, the diagnostic apparatus simply reads the analog signal from the 
interface specified in the "Interface & Protocol" field. If the interface has multiple signal lineSj the 

20 "ID" field should specify from which signal line of the interface the diagnostic apparatus should read 
the analog signal. 

Preferably, the computer 62 of the diagnostic apparatus includes conventional data collection 
software as described under the heading "Hardware Implementation". If so, in Step 606 the 
Attribute Look-Up software preferably passes the ID, the interface information, and the protocol 
25 information obtained in Step 605 to the data collection software, which employs the specified 
communications protocol to retrieve the attribute data from the UUT. 

Step 607: If the attribute record includes a "Conversion" field or "Scale Factor" field value, 
apply the conversion or scale factor specified in the attribute record. If the attribute record includes 
a "Physical Units" field value, store that value along with the attribute data. These fields are 



-19- 



wo 2004/079465 



PCT/US2004/003595 



explained below under the heading "Conversion to Physical Units." 

Conversion to Physical Units 

Each database record can further include a "Conversion" field that contains one or more 
subordinate fields, each of which stores a conversion parameter, such as a scale factor, for converting 
5 the analog or digital electrical signal outputted by the UUT to a physical unit of measurement for the 
attribute value identified by the "Attribute" field. An additional subordinate field of the 
"Conversion" field can specify the units of such physical unit of measurement, such as "watts", 
"degrees Celsius", **torr", or "seem". 

In many models of mainfi*ames conunercially sold by the assignee of this invention, the 

10 attribute data outputted by the mainframe is an N-bit binary number whose possible values range 
fi*om zero to 2^—1, where the binary values of zero and 2^—1 respectively represent a minimum 
physical value and a maximum physical value for the attribute. For such attributes, the 
"Conversion" field preferably consists of three subordinate fields: "Min", "Max" and "Units". The 
numerical values stored in the "Min" and "Max" fields are the physical attribute values represented 

15 by the attribute data having binary values of zero and 2^-1 , respectively. The value stored in the 
"Units" field designates the physical units in which such physical attribute values are expressed. 

For example, suppose that one of the attributes outputted by a mainframe is the temperature 
of the susceptor in the third chamber, and suppose that the range temperature measurements is 50° C 
to 550° C. Accordingly, the mainframe should output binary values in the range of zero to 2^-1 to 

20 represent temperatures in the range of 50° C to 550° C. In that case, values of "50" and "550" 
should be stored in the "Min" and "Max" fields, respectively, of the database record for the 
temperature of the susceptor in the third chamber, and the value "degrees Celsius" should be stored 
in the 'TJnits" field of that record. 

Version Ranges 

25 As described in the preceding sections entitled "Attribute Database" and "UUT Class Field," 

the "UUT Class" field of each database record identifies the class of equipment to which the 
remaining fields in the record pertain. In general, the class of UUT can be defined by the equipment 
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model, equipment version, or a combination of both. That is, the classes of UUT's may include 
various equipment models, and each model of UUT may be produced in various versions or 
generations having some differences in the specifications of their attributes. To enable the database 
to record the differences among various models of UUT's as woll as various versions or generations 
5 of each model, the "UUT Class" field of each database record is a combination field that includes a 
"Model" subordinate field and a "Version" subordinate field. In other words, each version of each 
model of mainfirame equipment is considered a distinct UUT Class. 

The value stored in the "Version" field to identify a version or generation may be, for 
example, a version number or a version date. The versions of a given model of UUT may differ fi-om 

10 each other in either their physical features or their operating software. If the versions differ firom 
each other in what diagnostic attributes the UUT outputs via its external confmiunications interface, 
or in the properties of the transmitted attributes (e.g., the respective ID's or conversion factors 
associated with one or more attributes), then it would be useful to employ the attribute database of 
the present invention to track these differences. 

15 The attribute database of the present invention is useful to tabulate differences betv^^een 

versions even when a diagnostic apparatus will only be connected to a single model of UUT 
equipment. In that case, there would be no need for the "Model" sub-field of the "UUT Class" field. 
In other words, the "UUT Class" field would simply be the "Version" field. 

Returning to the more general case in which the UUT Class is defined by both model and 

20 version, in one embodiment the attribute database contains a distinct set of records for each UUT 
class, and the set of records for a given UUT class includes a distinct record for each diagnostic 
attribute that can be outputted by that model and version of the UUT. For example, if a given model 
of mainfirame equipment has undergone 20 versions of software and/or hardware changes during its 
history, and if each version of that model has 30 attributes, then the database will require 600 records 

25 (20 versions multiplied by 30 attributes per version) to store the specifications of the attributes for 
all versions of that model. 

A more preferable embodiment of the attribute database reduces the required number of 
records by enabling the "Version" field of each attribute record to represent a range of versions 
instead of just a single version. Specifically, if the interface specifications and other properties of a 
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given diagnostic attribute remain the same for a range of versions of a given model of UUT, a single 
record is stored in the database to characterize that diagnostic attribute for all the versions within that 
range, rather than storing a distinct record for each version. 

Figure 3 shows the implementation of this technique in which the "Version" field in each 
5 database record is a compound field that includes two subordinate fields called "Version, First" and 
"Version, Last" whose contents respectively identify the first and last versions of the UUT model 
identified in the "Model" field to which the remaining fields of the record apply. In this embodiment 
of the invention, we define a "UUT Class" as a range of one or more versions of a specific model of * 
UUT. 

10 For example, suppose a mainfi:ame model called "Alpha" has undergone 20 revisions during 

its history. Suppose that in versions 1-7 of the Alpha mainfirame, the attribute "Pressure in 

Chamber 1" was assigned to logical port 33; in versions 8—16, this attribute was assigned a new 
logical port of 44; and in versions 17-20, this attribute was assigned to logical port 33 again. As 
shown in Figure 3, these revisions can be represented by three database records instead of twenty. 

15 Figure 4 shows an alternative embodiment in which the "Version" field can specify a plurality 

of versions that are not contiguous, and hence that cannot be defined as a range bounded by a first 
version and a last version. In this embodiment, the "Version" field can include any number of 
subordinate fields that each identify a version of the UUT model to which the record applies, so that 
the subordinate fields collectively identify a set of UUT versions. In the example of the preceding 

20 paragraph, the attribute "Pressure in Chamber 1" of Alpha can be represented by only two records in 
the database: one record for versions 1-7 and 18-20, and a second record for versions 8-17, as 
shown in Figure 4. The first database record has a "Version" field consisting of four subordinate 
fields called "1-Version, First", "1-Version, Last", "2- Version, First" and "2- Version, Last" in which 
are stored the respective values "1", "7", "17" and "20". 

25 Although versions conventionally are identified by version numbers, non-numeric names also 

can be used to identify different versions. 

Alternatively, versions can be identified by date rather than version number. For example, in 
the embodiment shown in Figure 2, the "Version" field of an attribute data record could store the 
release date, rather than a version number, of the UUT class to which that attribute data record 
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applies. Similarly, in the embodiment shown in Figure 3, the "Version, First" and "Version, Last" 
fields could store the first production date and the last production date of the UUT class to which 
the record applies, signifying that the attribute data record applies to all equipments of that UUT 
class that were produced between the specified first and last production dates. 

5 Database Normalization 

Figure 2, discussed extensively above, depicts the fields in a record of the attribute database. 
The identical database structure is depicted in Figure 7 in the form of a table. In the database tables 
shown in Figures 7 and 8, the notation "A:B" for a field name represents the sub-field named "B" of 
the compound field named "A". 

10 Figure 8 shows how the database can be at least partially normalized by dividing it into two 

tables called the "Attribute" table and the "Attribute Name & Chamber Config" table. To normalize 
the database, fields whose values rarely or never change independently of each other are grouped into 
a table. The normalized database reduces storage requirements by eliminating redundant fields in the 
records of the main database table, the Attribute table. 

15 In each database table, the first field listed is the key field of the table, which means that 

every record of the table has a different value stored in the key field. In the Attribute table, the ID is 
the key field because every attribute has a different ID. 

Diagnostic attributes that represent operating conditions or measurements for a process 
chamber, as opposed to the mainframe, usually are converted from analog measurements into digital 

20 attribute data using analog-to-digital converters within the chamber or within the measurement 
instrument attached to the chamber. Consequently, the conversion parameters (units and scale 
factor), as well as whether a parameter is read-only or read/write, usually are determined entirely by 
the chamber model and chamber configuration and are independent of the model and version of the 
UUT to which the chamber is connected. Logically, the conversion parameters also are independent 

25 of the chamber position on the mainfi*ame at which a given process chamber is mounted. Therefore, 
the database fields that represent the conversion parameters and the read/write flag can be moved 
from the Attribute table to a "child" table. 

Besides the conversion parameters and read/write flag, the additional fields included in the 
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"child" table are the fields necessary to uniquely determine the values of the conversion parameters 
and the read/write flag. These additional fields are, for the reasons explained in the preceding 
paragraph, the "Attribute: Name" field and the "Attribute: Chamber Model or Config" field. These 
two fields collectively define the key field of the database table. Therefore, the child table is named 

5 . the "Attribute Name & Chamber Config" table. The value stored in the key field for each record of 
the table can be either an arbitrary index number or can be formed by concatenating the values of the 
"Attribute: Name" field and the "Attribute: Chamber Model or Config" field for that record. 

The advantage of creating the "Attribute Name & Chamber Config" table is that Attribute 
table now only needs to include a single field for the "Attribute Name & Chamber Config Key" in 

10 place of the six fields previously required for the "Attribute: Name", "Attribute: Chamber Model or 
Config", "Read/Write", "Conversion: Units", "Conversion: Scale Factor: Min", and "Conversion: 
Scale Factor: Max". This reduces the storage required for the database. 
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CLAIMS 

1. A method of storing information in a database to characterize attributes outputted by different 
classes of equipment, comprising the steps of: 

providing a database memory device; 

storing in the database memory device a plurality of attribute data records, wherein the step 

of storing each attribute data record includes: 

storing in that record a first field identifying a class of equipment, 

storing in that record a second field identifying an attribute whose value is outputted 

by the class of equipment identified by the first field of that record, and 

storing in that record a third field specifying an ID which the class of equipment 

identified by the first field of that record assigns to the attribute value identified by the second field 

of that record. 

2. The method of claim 1, wherein, for each attribute data record, the ID stored in the third field 
uniquely specifies the attribute stored in the second field for the class of equipment stored in the first 
field. 

3. The method of claim 1, wherein, for each attribute data record, the ID stored in the third field 
uniquely specifies a command in response to which the class of equipment stored in the first field 
outputs the attribute stored in the second field. 

4. The method of claim 1, wherein, for each attribute data record, the ID stored in the third field 
uniquely specifies a command such that, in response to the class of equipment stored in the first field 
receiving said command, said class of equipment outputs the attribute stored in the second field. 

5. The method of claim 1 , wherein, for at least one attribute data record, the step of storing the 
second field further includes the step of: 

storing a fourth field identifying a position of a chamber connected to the class of equipment 
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identified in the first field. 

6. The metliod of claim 1, wherein, for each attribute data record, the first field identifies at least one 
model of equipment 

7. The method of claim 1, wherein, for each attribute data record, the first field identifies at least one 
version of equipment. 

8. The method of claim 1, wherein, for at least one attribute data record, the step of storing the first 
field includes: 

storing a first subordinate field that identifies a model of equipment; and 
storing a second subordinate field that identifies a version of the model of equipment 
identified in the first subordinate field. 

9. The method of claim 1, wherein, for at least one attribute data record, the step of storing the first 
field includes: 

storing first and second subordinate fields that collectively identify a range of versions of an 
equipment model. 

10. The method of claim 9, wherein the first and second subordinate fields respectively identify a 
first version and a last version in said range of versions. 

1 L The method of claim 1, wherein, for at least one attribute data record, the step of storing the first 
field includes: 

storing first and second subordinate fields that collectively identify a range of revision dates 
of an equipment model. 

12. The method of claim 1 1, wherein the first and second subordinate fields respectively identify a 
first revision date and a last revision date in said range of revision dates. 



wo 2004/079465 



PCT/US2004/003595 



13. The method of claim 1, wherein the step of storing a plurality of attribute database records 
comprises the steps of: 

storing in the database memory a first record including said first field, wherein the first field 
of the first record identifies a first class of equipment that includes a first model of equipment; and 

storing in the database memory a second record including said first field, wherein the first 
field of the second record identifies a second class of equipment that includes a second model of 
equipment different fi-om the first model. 

14. The method of claim 1, wherein the step of storing a plurality of attribute database records 
comprises the steps of: 

storing in the database memory a first record including said first field, wherein the first field 
of the first record identifies a first class of equipment that includes a first version of a first model of 
equipment; and 

storing in the database memory a second record including said first field, wherein the first 
field of the second record identifies a second class of equipment that includes a second version of said 
first model of equipment, the second version being different fi-om the first version. 

15. The method of claim 1, wherein, for at least one of the attribute data records, the attribute 
identified in the step of storing the first field is a measurement of a process being performed in a 
semiconductor fabrication process chamber. 

16. The method of claim 1, wherein, for at least one of the attribute data records, the attribute 
identified in the step of storing the first field is an operating condition of a process being performed 
in a semiconductor fabrication process chamber. 

17. A method of storing information in a database to characterize attributes outputted by different 
classes of equipment, comprising the steps of: 

providing a database memory device; 

storing in the database memory device a plurality of attribute data records, wherein the step 
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of storing each attribute data record includes: 

storing in that record a first field identifying a class of equipment, 

storing in that record a second field identifying an attribute whose value is outputted 

by the class of equipment identified by the first field of that record, and 

storing in that record a third field specifying a conversion parameter that defines a 

conversion of the value of the attribute identified in the second field into physical units of 

measurement. 

18. The method of claim 17, wherein, for at least one of the attribute data records, the conversion 
parameter stored in the third field specifies a physical unit of measurement 

19. The method of claim 17, wherein, for at least one of the attribute data records, the conversion 
parameter stored in the third field specifies a scale factor. 

20. The method of claim 17, wherein, for at least one of the attribute data records, the conversion 
parameter stored in the third field specifies a range of physical values. 

21. A diagnostic apparatus for monitoring electronic equipment, comprising: 

a computer-readable data storage device in which a plurality of data records are stored, 
wherein each data record includes: 

a first data field that stores data identifying a class of equipment, 
a second data field that stores data identifying an attribute whose value is outputted 
by the class of equipment identified by the first field of that record, and 

a third data field that stores data specifying an ID which the class of equipment 
identified by the first field of that record assigns to the attribute value identified by the second field 
of that record; and 

a computer connected to read data from the data storage device. 
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22. The apparatus of claim 21, fiirther comprising: 

a communications interface capable of being connected to receive data from the class of 
equipment identified in one of the data records; 

wherein the computer is connected to read data from the communications interface. 

23. The apparatus of claim 21, wherein, for each attribute data record, the ID stored in the third field 
xmiquely specifies the attribute stored in the second field for the class of equipment stored in the first 
field. 

24. The apparatus of claim 21, wherein, for each attribute data record, the ID stored in the third field 
uniquely specifies a command in response to which the class of equipment stored in the first field 
outputs the attribute stored in the second field. 

25. The apparatus of claim 21, wherein, for each attribute data record, the ID stored in the third field 
uniquely specifies a command such that, in response to the class of equipment stored in the first field 
receiving said command, said class of equipment outputs the attribute stored in the second field. 

26. The apparatus of claim 21, wherein at least one attribute data record further includes a fourth 
data field that stores data identifying a position of a chamber connected to the class of equipment 
identified in the first field. 

27. The apparatus of claim 21, wherein, for each attribute data record, the first field stores data 
identifying at least one model of equipment, 

28. The apparatus of claim 21, wherein, for each attribute data record, the first field stores data 
identifying at least one version of equipment. 

29. The apparatus of claim 21, wherein, for at least one attribute data record, the first data field 
includes: 
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a first subordinate field that stores data identifying a model of equipment; and 
a second subordinate field that stores data identifying a version of the model of equipment 
identified in the first subordinate field. 

30. The apparatus of claim 21, wherein, for at least one attribute data record, the first data field 
includes: 

first and second subordinate fields that store data that collectively identify a range of versions 
of an equipment model. 

31. The apparatus of claim 30, wherein the data stored in the first and second subordinate fields 
respectively identify a first version and a last version in said range of versions. 

32. The apparatus of claim 21, wherein, for at least one attribute data record, the first data field 
includes: 

first and second subordinate fields that store data that collectively identify a range of revision 
dates of an equipment model. 

33. The apparatus of claim 32, wherein the data stored in the first and second subordinate fields 
respectively identify a first revision date and a last revision date in said range of revision dates. 

34. The apparatus of claim 21, wherein the plurality of attribute database records stored in the 
computer-readable data storage device include: 

a first record including said first field, wherein the data stored in the first field of the first 
record identifies a first class of equipment that includes a first model of equipment; and 

a second record including said first field, wherein the data stored in the first field of the 
second record identifies a second class of equipment that includes a second model of equipment 
different from the first model. 
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35. The apparatus of claim 21, wherein the plurality of attribute database records stored in the 
computer-readable data storage device comprises: 

a first record including said first field, wherein the data stored in the first field of the first 
record identifies a first class of equipment that includes a first version of a first model of equipment; 
and 

a second record including said first field, wherein the data stored in the first field of the 
second record identifies a second class of equipment that includes a second version of said first model 
of equipment, the second version being different fi-oni the first version. , , 

36. The apparatus of claim 21, wherein, for at least one of the attribute data records, the attribute 
identified by the data stored in the first field is a measurement of a process performed in a 
semiconductor fabrication process chamber. 

37. The apparatus of claim 21, wherein, for at least one of the attribute data records, the attribute 
identified by the data stored in the first field is an operating condition of a process performed in a 
semiconductor fabrication process chamber. 

38. A diagnostic apparatus for monitoring electronic equipment, comprising: 

a computer-readable data storage device in which a plurality of data records are stored, 
wherein each data record includes: 

a first data field that stores data identifying a class of equipment, 
a second data field that stores data identifying an attribute whose value is outputted 
by the class of equipment identified by the first field of that record, and 

a third data field that stores data specifying a conversion parameter that defines a 
conversion of the value of the attribute identified in the second field into physical units of 
measurement; and 

a computer connected to read data from the data storage device. 
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39. The apparatus of claim 38, wherein, for at least one of the attribute data records, the conversion 
parameter stored in the third field specifies a physical unit of measurement. 

40. The apparatus of claim 38, wherein, for at least one of the attribute data records, the conversion 
parameter stored in the third field specifies a scale factor. 

41. The apparatus of claim 38, wherein, for at least one of the attribute data records, the conversion 
parameter stored in the third field specifies a range of physical values. 

42. A data storage medium for storing data that describes one or more attributes of at least one class 
of equipment, comprising: 

a computer-readable data storage mediimi in which a plurality of data records are stored, 

wherein each data record includes: 

a first data field that stores data identifying a class of equipment, 

a second data field that stores data identifying an attribute whose value is outputted 

by the class of equipment identified by the first field of that record, and 

a third data field that stores data specifying an ID which the class of equipment 

identified by the first field of that record assigns to the attribute value identified by the second field 

of that record. 

43. A data storage medium for storing data that describes one or more attributes of at least one class 
of equipment, comprising: 

a computer-readable data storage medium in which a plurality of data records are stored, 

wherein each data record includes: 

a first data field that stores data identifying a class of equipment, 

a second data field that stores data identifying an attribute whose value is outputted 

by the class of equipment identified by the first field of that record, and 

a third data field that stores data specifying a conversion parameter that defines the 

conversion of the value stored in the second field into physical units of measurement. 
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44. A computer-readable data storage medium in which is stored instructions executable by a 
computer to perform method steps for storing database records in a data storage device, wherein: 

the method steps comprise the step of storing in a data storage device a plurality of attribute 
data records; and 

said step of storing each attribute data record includes: 

storing in that record a first field identifying a class of equipment, 
storing in that record a second field identifying an attribute whose value is outputted 
by the class of equipment identified by the first field of that record, and 

storing in lhat record a third field specifying an ID which the class of equipment 
identified by the first field of that record assigns to the attribute value identified by the second field 
of that record. 

45. A computer-readable data storage medium in which is stored instructions executable by a 
computer to perform method steps for storing database records in a data storage device, wherein: 

the method steps comprise the step of storing in a data storage device a plurality of attribute 
data records; and 

said step of storing each attribute data record includes: 

storing in that record a first field identifying a class of equipment, 
storing in that record a second field identifying an attribute whose value is outputted 
by the class of equipment identified by the first field of that record, and 

storing in that record a third field specifying a conversion parameter that defines a 
conversion of the value of the attribute identified in the second field into physical units of 
measurement. 
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ID (KEY) 
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